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DETAILED ACTION 

Continued Examination Under 37 CFR 1. 1 14 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1 .1 7(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 

1 1/22/10 has been entered. 

Claim Rejections - 35 USC §112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

3. Claim 1 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

Claim 1 recites "A method for determining whether to accept a new call to be 
routed from the first gateway to a second gateway in an IP network". There is 
insufficient antecedent basis for "the first gateway" in the claim. 

For purpose of continuation of the prosecution, the claims will be interpreted as 
best understood. 

4. The following is a quotation of the first paragraph of 35 U.S.C. 1 1 2: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 
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5. Claims 1-33 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the written description requirement. The claim(s) contains subject matter 
which was not described in the specification in such a way as to enable one skilled in 
the art to which it pertains, or with which it is most nearly connected, to make and/or use 
the invention. 

Claim 1 recites the limitation "each of said network paths being associated with 
respective first gateway egress interfaces and a second gateway system IP address". 
There is insufficient support in the specification for this limitation in the claim. 

Note that Applicant stated during telephone interview that the support of this 

limitation is in page 6, line 18-31, which reads as follows: 

Packets traveling to a destination gateway can follow different paths based on the port 206x 
chosen for the specific RTP flow. The MBCAC algorithm assumes that the selection of a port 206x for an 
incoming call request is under the control of a call controller in the gateway. Hence, the MBCAC algorithm 
keeps separate admission policies for the paths from different ports to the same destination gateway. It is 
also assumed that multiple calls going from a particular port to the same destination gateway follows the 
same path, i.e., there is no load balancing within the network other than 25 provided by the gateways 
through the selection of an egress port. This assumption can be satisfied if the gateways use the system 
IP address of the destination gateway as opposed to the IP addresses of its ports. In this framework, load 
balancing is supported by controlling the egress port at the source gateway (i.e., first gateway 114). Since 
each egress port would map into a unique path in the IP network 118, the load from source gateway 114 
to a destination gateway (i.e., second gateway 116) can be partitioned into different paths, resulting in 
load sharing in the network 

However, the above cited text does not disclose "first gateway egress interfaces" 
in the claim language. 

Claims 2-33 are rejected because they depend from claim 1 . 

Claim 31 recites the limitation "using all of the network congestion parameters". 
There is insufficient support in the specification for this limitation in the claim. 

Note that Applicant argues the support is in "on pg. 9, Lines 13 - 16 of Applicants' 
application, which discusses an admission control algorithm that is used to determine if there is an 
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uncongested path from the first gateway to the second gateway (i.e., looking at more than one, and 
possibly all, of the paths from the first gateway to the second gateway)." 

Page line 13-16 reads "Next, first gateway 1 14 consults with the admission control algorithm 
to see if there is a path to the second gateway 1 16 that is not congested. If first gateway 1 14 is 
15 unable to find an uncongested path to second gateway 1 16 it sends an error message at step 414 to 
the Softswitch 112..." 

The cited text does not disclose "all of the network congestion parameters". 
Claim 32 has the same problem because it depends from claim 31 . 
For purpose of continuation of the prosecution, the claims will be interpreted as 
best understood. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. Claims 1, 3, 5, 14-15, 18, 23, 26 and 33 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Elliott et al (US 20040022237, hereinafter Elliott) in view of 
Szabo (US 20020003779 A1). 

For claim 1 , Elliott discloses a method for determining whether to accept a new 
call (a call between phone 102 and phone 120, FIG. 1) to be routed from a first gateway 
(gateway 1 08 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) to a second gateway 
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(gateway 1 10 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) in an IP network (VoIP, 
[0453] and FIG. 1), comprising the steps of: 

obtaining, at the first gateway, information indicative of to the quality of service 
("latency or packet loss", [0099] in view of Fig. 21 B) of voice calls being transmitted from 
the first gateway to a second gateway via a plurality of network paths between the first 
gateway and the second gateway (data network 1 12 of FIG. 1 or 21 B that has a plurality 
of network paths between the two gateways); 

determining, using at least a portion of said information, a plurality of congestion 
status parameters indicative of respective congestion statuses of the network paths 
("latency or packet loss", [0099] in view of Fig. 21 B); and 

Elliott does not specifically disclose determining, using at least one of the 
congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths, 
each of said network paths being associated with respective first gateway egress 
interfaces and a second gateway system IP address. 

In the same field of endeavor, Szabo discloses determining, using at least one of 
the congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths 
("at least one performance indicator value read from the RTCP mechanism does not 
exceed a pre-set threshold value, the call is accepted", [0028]), each of said network 
paths being associated with respective first gateway egress interfaces and a second 
gateway system IP address (suggested by "a method is described in B. Thompson et al. 
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"Tunnelling Multiplexed Compressed RTP", Internet Draft, March 2000, Work in 
Progress, wherein a multitude of RTP/UDP/IP packets are compressed and multiplexed 
into a so-called PPP packet", [0005]; note that a UDP/IP tunnel is a path be associated 
with the IP address and egress port of each of two end points of the tunnel). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
Elliott for the benefit of ensuring "a transmission path with acceptable transmission 
quality" ([0008] of Szabo). 

For claim 14, Elliott discloses an apparatus (soft switch 204 in FIG. 2 and 3, with 
circuit being the means for implementing logic in the soft switch) comprising a first 
gateway for interfacing voice call data from a public switch telephone network to an 
Internet Protocol network; said first gateway further comprising: 

for determining whether to accept a new call to be routed from a first gateway 
(gateway 1 08 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) to a second gateway 
(gateway 1 10 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) in an IP network (VoIP, 
[0453] and FIG. 1), comprising the steps of: 

a first circuit for passing the voice call data to the internet protocol network (the 
Soft Switch 204 in FIG. 2B); 

a second circuit for polling the internet protocol network about traffic information 
transmitted therein (the Soft Switch 304 in FIG. 2B); and 

a third circuit for: calculating, based on the received quality-of-service 
information, a plurality of congestion status parameters associated with the respective 
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network paths between the first gateway and the second gateway, wherein the 
congestions status parameters are indicative of respective congestion statuses of the 
network paths (the circuit in the first gateway responsible for calculating quality-of- 
service information such as ("latency or packet loss", [0099]); and 

obtaining, at the first gateway , information indicative of to the quality of service 
("latency or packet loss", [0099] in view of Fig. 21 B) of voice calls being transmitted from 
the first gateway to a second gateway via a plurality of network paths between the first 
gateway and the second gateway (data network 1 1 2 of FIG. 1 or 21 B that has a plurality 
of network paths between the two gateways); and 

determining, using at least a one of the congestion status parameters_("latency or 
packet loss", [0099] in view of Fig. 21 B). 

Elliott does not specifically disclose determining, using at least one of the 
congestion status parameters, whether to accept the new voice call into the network at 
the first circuit for transmission toward the second gateway via one of the network paths 

In the same field of endeavor, Szabo discloses determining, using at least one of 
the congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths 
("at least one performance indicator value read from the RTCP mechanism does not 
exceed a pre set threshold value, the call is accepted", [0028]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
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Elliott when determining whether to accept a new call or not to ensure the new call will 
function properly and QoS condition of the network is satisfied. 

As to claim 23, Elliott in view of Szabo claim 1 , Elliott is silent on accepting the 
new call into the IP network at the first gateway for transmission toward the second 
gateway via one of the network paths, wherein the new call is accepted into the IP 
network in the case of the congestion status parameter associated with the one of the 
network paths not exceeding an upper threshold. 

In the same field of endeavor, Szabo discloses accepting the new call into the IP 
network in the case of said parameter not exceeding an upper threshold ("at least one 
performance indicator value read from the RTCP mechanism does not exceed a pre- 
set threshold value, the call is accepted", [0028]; note that RTCP is a protocol for the 
IP network). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
Elliott when determining whether to accept a new call or not according to KSR to ensure 
the new call will function properly and QoS condition of the network is satisfied. 

As to claim 3, Elliott in view of Szabo discloses the method of claim 23, Elliott is 
silent on said new call is not accepted into the IP network in the case of the congestion 
status parameter associated with the one of the network paths exceeding the upper 
threshold. 

Szabo further discloses said new call is not accepted into the IP network in the 
case of the congestion status parameter associated with the one of the network paths 
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exceeding the upper threshold ("one performance indicator value exceeds a pre-set 
threshold value, the IP telephony gateway rejects the call in a step 209", [0028]; note 
that the performance indicator is a congestion status parameter). The motivation of 
combination is the same. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to reject a new call in order to reduce the network congestion. 

As to claim 5, Elliott in view of Szabo discloses the method of claim 1 , Elliott 
further discloses wherein the obtained information comprises, for each of at least one of 
the network paths, a delay of received packets transmitted from the first gateway to the 
second gateway via the network path (unacceptable latency, [1493], line 4). 

As to claim 15, Elliott in view of Szabo discloses claim 14, Elliott further 
discloses said first circuit further comprises one or more Ethernet cards ("Soft switches 
204a, 204b and 204c are connected ... via redundant Ethernet switches", [0568], which 
suggest Ethernet interfaces with software switches as the first circuit) that are 
connected to the Internet protocol network. 

As to claim 18, Elliott in view of Szabo discloses claim 14, Elliott further 
discloses the third circuit determining whether the new voice call is to be accepted into 
the internet protocol network via the first circuit, by comparing each of at least one of the 
congestion status parameter to at least one thresholds (Packet Loss Threshold, Table 
147 - continued, page 85, where packet loss values can be used as the thresholds for 
determining if the new voice call is to be accepted or not). 
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As to claim 26, Elliott in view of Szabo discloses claim 1 , wherein determining 
whether to accept the new call into the network at the first gateway is made using call 
control logic (as discloses in the parent claim 1), wherein the call control logic is 
updated using the congestion status parameters (this limitation is the same as the last 
paragraph of claim 1 in that the call control logic is the one that the determining is based 
on). 

As to claim 33, Elliott in view of Szabo claim 1 , wherein determining whether to 
accept the new call into the network at the first gateway comprises: 

for each of at least one of the network paths, updating a call admission control 
policy for the network path based on the congestion status parameter determined for 
the network path; and determining whether to accept the new call into the network at the 
first gateway based on the updated call admission control policy (as disclosed by the 
parent claims 1 ; note accepting the new call "using at least one of congestion status 
parameter" is updating a call admission control policy for the network path based on the 
congestion status parameter). 

8. Claims 4, 6-10, 19-22, 24-25 and 27-32 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Elliott in view of Szabo, further in view of Schulzrinne et al., 
ITEF RFC 3550, July 2003 (hereinafter RFC 3550). 

As to claim 4, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information obtained is a number of send packets to said second location 
via the network path, wherein the number of sent packets comprises a number of lost 
packets, a number of late packets and a number of received packets. 
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RFC 3550 discloses the information obtained is a number of packets sent to said 
second location via the network path (Line 1 of the paragraph for "Sequence number: 
16 bits", Page 14, where lost packets are those with missing sequence number), 
wherein the number of sent packets comprises a number of lost packets, a number of 
late packets (Line 1 of the paragraph for "Sequence number: 16 bits", Page 14, where 
late packets inherently are packets that have been sent, but have not been received 
according to their sequence numbers) and a number of received packets (sequence 
number provides information on a number of received packets). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 6, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information obtained is a delay variation (variation in the delay, Line 5 of 
last paragraph in Page 44) of received packets transmitted from said first location to 
said second location via the network path. 

RFC 3550 further discloses wherein the information obtained is a delay variation 
(variation in the delay in RTCP packet, last paragraph in Page 44) of received packets 
transmitted from said first location to said second location via the network path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
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disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 7, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information is obtained on a periodic basis 

RFC 3550 further discloses the information is obtained on a periodic basis 
("based on periodic transmission", first paragraph in Page 19). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 8, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information is obtained on an exception basis using an immediate report. 

RFC 3550 further discloses the information is obtained on an exception basis 
using an immediate report (Receiver report, first line of Section 6.4 in Page 35). The 
motivation of combination is the same as described in the parent claim above. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 9, Elliott in view of RFC 3550 and Szabo discloses the method of 
claim 1 , but is silent on the parameter including packet lost ratio. 



Application/Control Number: 10/657,864 Page 13 

Art Unit: 2462 

RFC 3550 further discloses wherein the parameter include packet lost ratio 
(packet lost ratio, Line 1 of 3 rd paragraph of Section 6.4.4, Page 43). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 10 and 19, Elliott in view of Szabo discloses 1 and 14, but is silent on 
wherein PLR is defined as 

(lost packets + late packets) 

PLjR — ■ . 

(received packets +- lost packets + late packets) 

RFC 3550 discloses, by definition, PLR is the ratio of the number of packets NOT 
received to number of the total packets sent for a given period of time (such as 
disclosed by "The ratio of these two is the packet loss fraction over the interval" in last 
paragraph of page 43 in RFC 3550); The PLR formula above is simply a math 
expression of the definition; note that the number of packets that are NOT received 
equal to the sum of the number of lost packets and the number of last packets {last 
packets are the packets that are not received during the time interval but may be 
received at a later time). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
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disclosed by Elliott in view of Szabo for the benefit of calculating PLR using formula 
shown above for gaining a better understanding of network performance status. 

As to claim 20, Elliott in view of Szabo discloses claim 19, Elliott further 
discloses the traffic processing (including new call setup) depends on QoS parameters, 
including packet loss performance ([1081]); 

Elliott does not explicitly disclose the new call is accepted if PLR is below a given 
threshold; 

however, PLR is just one commonly used QoS parameter; 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is accepted if PLR that is (calculated by the third 
circuit, CPU) is below a given threshold for the benefit of providing reliable network 
service for users. 

As to claim 21, Elliott in view of Szabo and RFC 3550 discloses of claim 19, 
Elliott further discloses the third circuit compares the packet loss ratio; 

Elliott does not explicitly disclose the new call is accepted using a reduced 
bandwidth if PRL is between given low threshold and the upper threshold; 

however, PRL is commonly used QoS parameter ([1081]); and Elliott also 
teaches providing different network services depend on QoS parameters, such as delay 
and packet loss information ([1088]); 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is accepted using a reduced bandwidth if PRL that is 
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(calculated by the third circuit, CPU) is between given low threshold and the upper 
threshold for the benefit of providing reliable network service for users. 

As to claim 22, Elliott in view of Szabo and RFC 3550 discloses claim 19. 

Elliott does not explicitly disclose the new voice call is accepted if PLR is below a 
given threshold; 

however, PLR is commonly used as aQoS parameter ([1081]); 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is blocked if PLR that is (calculated by the third circuit, 
CPU) is above the upper threshold for the benefit of protecting normal network 
operation. 

As to claim 24, Elliott in view of Szabo discloses claim 1 , but is silent on the 
information indicative of the quality of service of voice calls being transmitted from the 
first gateway to the second gateway comprises a plurality of performance reports 
associated with the voice calls, wherein determining the congestion status parameters 
of the network paths comprises: determining, for each of the performance reports, one 
of the network paths with which the performance report is associated; and determining, 
for each of the network paths, the congestion status parameter of the network path 
using at least a portion of the performance reports determined to be associated with the 
network path. 

RFC 3550 discloses the information indicative of the quality of service of voice 
calls being transmitted from the first gateway to the second gateway comprises a 
plurality of performance reports associated with the voice calls ("sender report (SR) and 
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receiver report (RR)", 1 st paragraph of Section 6.4, page 35), wherein determining the 
congestion status parameters of the network paths comprises: determining, for each of 
the performance reports, one of the network paths with which the performance report is 
associated (SSRC_1 ... SSRC_n in SR shown in SR packet in Section 6.4.1 of page 36 
shows the network path associated with the report); and determining, for each of the 
network paths, the congestion status parameter of the network path using at least a 
portion of the performance reports determined to be associated with the network path 
(one of congestion status parameters "fraction lost", "cumulative number of packets 
lost", and "delay since last SR (DLSR)", 1 st paragraph of Section 6.4, page 35). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 

As to claim 25, Elliott in view of Szabo discloses claim 1 , but does not 
specifically discloses the information indicative of the quality of service of voice calls 
being transmitted from the first gateway to the second gateway comprises a plurality of 
performance reports associated with the voice calls, wherein determining the 
congestion status parameters of the network paths comprises: for each of at least one 
of the network paths: selecting only a subset of the performance reports associated with 
the network path; and determining the congestion status parameter of the network path 
using the selected subset of the performance reports associated with the network path. 

RFC 3550 discloses the information indicative of the quality of service of voice 
calls being transmitted from the first gateway to the second gateway comprises a 
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plurality of performance reports associated with the voice calls ("sender report (SR) and 
receiver report (RR)", 1 st paragraph of Section 6.4, page 35), wherein determining the 
congestion status parameters of the network paths comprises: for each of at least one 
of the network paths (each report is for a path): selecting only a subset of the 
performance reports associated with the network path (congestion status parameters 
"fraction lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 
1 st paragraph of Section 6.4, page 35, are a subset of the report); and determining the 
congestion status parameter of the network path using the selected subset of the 
performance reports associated with the network path (congestion status parameters 
"fraction lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 
1 st paragraph of Section 6.4.1 , page 36, are a subset of the report). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 

As to claim 27, Elliott in view of Szabo discloses claim 26, but is silent on for 
each of at least one of the network paths, the call control logic is updated using the 
congestion status parameter for the network path periodically. 

RFC 3350 discloses for each of at least one of the network paths, the call control 
logic is updated using the congestion status parameter (one of congestion status 
parameters "fraction lost", "cumulative number of packets lost", and "delay since last SR 
(DLSR)", 1 st paragraph of Section 6.4, page 35,) for the network path periodically ("each 
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periodically transmitted compound RTCP packet MUST include a report packet", 1 st 
paragraph of page 22, Section 6.1). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 

As to claim 28, Elliott in view of Szabo discloses claim 26, wherein, for each of at 
least one of the network paths, the call control logic is updated using the congestion 
status parameter for the network path on an exception reporting basis ("Sender and 
Receiver Reports", Section 6.4 page 35-45; note that Sender and Receiver Reports are 
exception reporting because they provide exception information like "fraction lost", 
"cumulative number of packets lost"). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 29, Elliott in view of Szabo discloses claim 1 , Elliott further discloses 
the first gateway comprise a plurality of ports (FIG. 1 shows each gateway 108 and 110 
has a plurality of ports) associated with the respective plurality of network paths (FIG. 1 
shows plurality of network paths via Data network 1 1 2), for each network path: for each 
of at least one voice call being transmitted from the first gateway to the second gateway 
via the network path (as shown in FIG. 1). 

Elliott is silent on, computing a congestion status value associated with the voice 
call using the obtained information associated with the voice call; and determining the 
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congestion status parameter of the network path using the at least one congestion 
status value computed for the network path. 

RFC 3550 discloses computing a congestion status value associated with the 
voice call using the obtained information associated with the voice call; and determining 
the congestion status parameter of the network path using the at least one congestion 
status value computed for the network path (each voice call has a path and is 
associated with the specific report that includes congestion status parameters "fraction 
lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 1 st 
paragraph of Section 6.4.1 , page 36). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 30, Elliott in view of Szabo claim 29, but is silent on the congestion 
status parameter for the network path is determined by selecting the congestion status 
value computed for the network path that is indicative of the greatest amount of 
congestion on the network path 

RFC 3550 discloses the congestion status parameter for the network path is 
determined by selecting the congestion status value computed for the network path that 
is indicative of the greatest amount of congestion on the network path (each voice call 
has a path and is associated with the specific report that includes congestion status 
parameters "fraction lost", "cumulative number of packets lost", and "delay since last SR 
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(DLSR)", 1 st paragraph of Section 6.4.1 , page 36; e.g., select the greatest amount of 
delay because all other delay value is irrelevant anymore). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 31, Elliott in view of Szabo claim 1 , but is silent on the determination 
as to whether to accept the new call into the network at the first gateway is performed 
using all of the network congestion parameters. 

RFC 3550 discloses the determination as to whether to accept the new call into 
the network at the first gateway is performed using all of the network congestion 
parameters (each voice call has a path and is associated with the specific report that 
includes congestion status parameters "fraction lost", "cumulative number of packets 
lost", and "delay since last SR (DLSR)", 1 st paragraph of Section 6.4.1, page 36; all 
these parameters can be used for determination as to whether to accept the new call 
into the network). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 32, Elliott in view of Szabo and RFC 3550 discloses claim 31 , Elliott 
further discloses on accepting the new call into the IP network at the first gateway for 
transmission toward the second gateway via one of the network paths (as disclosed by 
the parent claims 1 ; note that the new call is always accepted via one the network 
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paths), wherein the one of the network paths for the new call is the one of the network 
paths having the associated congestion status parameter indicative of the least amount 
of congestion (as disclosed by the parent claims 1 : claim 1 discloses congestion 
information for different paths among which there is one path that has the least amount 
of congestion). 

9. Claims 2 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elliott in view of Szabo, further in view of Watt (US Patent number 5781532, hereinafter 
Watt). 

As to claim 2, Elliott in view of Szabo discloses the method of claim 23, but are 
silent on wherein new call may be accepted at a reduced bandwidth in the case of said 
parameter exceeding a lower threshold. 

In the same field of endeavor, Watt discloses adjusting transmission rate in 
response to a "mild" congestion state, as indicated by the value packet loss ratio 
exceeding a lower threshold but below an upper threshold, "adjusting {he transmission 
rate in response to the detection of said congestion ... when the detected congestion 
exceeds a predetermined mild congestion threshold', from line 21 of col. 7 to line 3 of 
col. 8). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to accept a new call at a reduced bandwidth in order to fully 
take advantage of network resource. 

As to claim 13, Elliott in view of Szabo and Watt discloses the method of claim 2, 
Elliott disclose further discloses wherein the bandwidth of a newly accepted call is 
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reduced by activating the characteristic of silence suppression for said newly accepted 
voice call (silence suppression activation timer, table 147 in Page 85). 

1 0. Claims 11-12 are rejected under 35 U.S. C. 1 03(a) as being unpatentable over 
Elliott in view of Szabo and Watt, further in view of RFC 3550. 

As to claim 11, Elliott in view of Szabo and Watt discloses claim 2, Elliott further 
discloses using different encoders (CODECS, such as ones supporting G.71 1 , G. 726, 
and G.728 in [1004]) to handle different connections with different bandwidth ([1004]); 
which include the case of using 2 different encoders to handle 2 different kinds of calls 
that have different bandwidth. 

As to claim 12, Elliott in view of RFC 3550 and Szabo discloses the method of 
claim 2, but are silent on wherein the bandwidth of a newly accepted call is reduced by 
increasing the packet size for said newly accepted voice call. 

However, for a given amount of data, increasing the packet size will decrease the 
overhead caused by packet header therefore reduce the required bandwidth for the call, 
(this is demonstrated by efficiency factor e=(packet_size)/( packet_size+header_size); 
for a fixed header size, the larger is the packet_size, the larger is e); 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to increase the packet size so as to decrease the required 
bandwidth for the call for the benefit of saving bandwidth resource. 

1 1 . Claims 16-17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elliott in view of RFC 3550 and Szabo, further in view of Hooper et al (US 20040252686 
A1) (hereinafter Hooper). 
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As to claim 16, Elliott in view of Szabo discloses the apparatus of claim 14, but 
are silent on said second circuit is at least one strongarm card. 

However, the second circuit is simply a CPU card (such as CPU card of Soft 
Switch 204, FIG. 2B) that implement the logic of receiving QoS information associated 
with voice calls, and strongarm is a popular CPU that is commonly used in the CPU 
cards as disclosed by Hooper ("the core processor implemented as a Strong Arm 
architecture", [0010]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to use strongarm CPU card as the circuit disclosed by Elliott for 
the benefit of cost saving. 

As to claim 17, Elliott in view of Szabo and Hooper discloses the apparatus of 
claim 16, Elliott further discloses the CPU card (with strongarm CPU) is connected to 
the Ethernet card via a host CPU circuit (CPU card of Soft Switch 204 is connected to 
Ethernet switches 332, [0568], line 1-5 and FIG. 2B). 

Response to Amendments/Remarks 
12. Applicant's arguments and all other documents filed on 11/22/10 have been fully 
considered but are not moot because all claims have been amended to which new 
ground rejections are made. For details See the rejection addressing new amendment 
above. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jianye Wu whose telephone number is (571)270-1665. 
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The examiner can normally be reached on Monday to Thursday, 8am to 7pm. If 
attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Seema Rao can be reached on (571)272-3174. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO 
Customer Service Representative or access to the automated information system, call 
800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Jianye Wu/ 
Examiner, Art Unit 2462 



